Modern high performance electronic circuitry has an ever-increasing number of circuit elements and an ever-rising clock frequency. As circuitry performance continues to increase, the result has been a larger number of circuits switching at faster rates. After a circuit prototype is initially manufactured and failure modes are uncovered, determining failure mechanisms is time intensive due to the increased circuit complexity. Circuit failures may be the result of logic errors or poor manufacturability of a circuit element. In both cases, simulation of the circuit helps to confirm or refute the existence of a logic error and verify the correctness of the design.
Simulation may occur at low levels of abstraction, e.g., at a “switch-level.” Switch-level simulations typically include active circuit elements (e.g., transistors) and passive circuit elements (e.g., resistors, capacitors, and inductors). CPU simulation also may occur at a higher level of abstraction, e.g., a “behavioral level.” Behavioral level simulations typically use a hardware description language (HDL) that determines the functionality of a single circuit element or group of circuit elements. Examples of typical behavioral level simulation languages are Very High Speed Integrated Circuit HDL (VHDL) and Verilog. Using Verilog, for example, electronic circuitry is described as a set of modules, each of which is part of a design of a circuit, circuits, or a device. Modules can represent elements of hardware ranging from simple gates to complete systems.
Designers may use assertions to detect design errors and verify design correctness during simulations. An assertion is an expression written in a computer language (in HDL, for example), which asserts that at a certain time during the simulation, a certain signal (or combination of signals) in the design equals a certain value or values. For example, an assertion included in a design may assert that value of an output of a particular gate is equal to “1” at 1000 seconds into the simulation (or at a particular cycle of the simulation, e.g., the 500th cycle of the simulation). If the assertion fails, i.e., if the value of an output of the gate is not equal to “1” at 1000 seconds into the simulation, then the simulator in which the simulation is executing may stop, or display a warning, or perform some other appropriate action.
FIG. 1 shows a system for using assertions to detect design errors during a simulation. The system includes a design (20), a compiler (22), a simulation image (24), assertions (26), a connectivity database (28), a simulator (30), a simulation toolkit (32), a waveform trace (34), and node data (36). The design, (e.g., Verilog modules) (20), is compiled by the compiler (22), which generates the simulation image (24), including the assertions (26). The connectivity database (28), also generated by the compiler (22), is typically made available to a designer conducting the simulation via the simulation toolkit (32).
The simulation image (24) is typically a binary executable file including instructions for performing the simulation on a simulator (30). The assertions (26) are a set of instructions (typically written in a high-level computer programming language) asserting the value of circuit elements of the design (20) at particular points in the simulation. For example, the assertions (26) may include an instruction to the simulator (30) to assert that the output of a particular AND gate is equal to “1” 1000 seconds after the start of the simulation. A simulation toolkit (32) is software used by a designer to control the simulation. The simulation toolkit (32) typically includes software to control the other parts of the system, and to obtain and present sufficient data to allow the designer to control the simulation and later debug errors in the design that are uncovered during the simulation. As such, the simulation toolkit (32) may include appropriate Command Line Interface (CLI) and Graphical User Interface (GUI) tools.
The connectivity database (28) provides a connectivity description for the circuit elements of the design (20). The connectivity description describes how the circuit elements are connected to each other. For example, the connectivity database (28) provides a connectivity description describing connections to other circuit elements for the previously mentioned AND gate. For example, the connectivity database (28) describes the AND gate as having two inputs, each of which is a signal driven by a particular circuit element (such as a another gate, etc.), where each circuit element has other inputs. Thus, a circuit element of the design (20) may be represented as a node in a graph, with inputs and outputs of the node represented as edges connecting to other nodes of the design (20).
If an assertion is associated with a particular node, then each set of drivers (e.g., each circuit element providing signal inputs into the node) may be represented as a tree structure called a fanin cone. The root of the fanin cone is the node associated with the assertion. FIG. 2 shows a fanin cone (40) for an assertion (42), which has two drivers, node 1 (44), and node 2 (46). Node 1 (44) has three drivers, node 3 (48), node 4 (50), and node 5 (52). Because node 3 (48), node 4 (50), and node 5 (52) do not have drivers, node 3 (48), node 4 (50), and node 5 (52) are considered primary inputs, and are leaf nodes of the fanin cone (40). Likewise, node 2 (46) has two drivers, node 6 (54) and node 7 (56), which are primary inputs.
Referring back to FIG. 1, during the simulation, the designer uses the simulation toolkit (32) to determine which nodes are drivers of a failed assertion. The designer uses the node data (36) from the waveform trace (34) to determine the cause of the assertion failure. However, the waveform trace (34) includes waveforms (signals) for each of the multiple nodes of the design, which may include thousands of nodes. In order to minimize the amount of node data that the designer uses to debug the assertion failure, the designer may obtain a fanin cone for the particular assertion associated with the assertion failure. Thus, the simulation toolkit may include software for tracing the fanin cone for a failed assertion (using, for example, well-established graph theory algorithms). Next, the designer may obtain minimal node data by selecting only those waveforms from the waveform trace (34) that pertain to the fanin cone.
FIGS. 3 and 4 show a flowchart of operations for a simulation using the system shown in FIG. 1 to verify a design. A first operation is obtaining the design and assertions for the design (Step 80). Then, the assertions are inserted into the design (Step 82). The design is compiled using a compiler to generate a simulation image (Step 84). Compiling the design also generates the connectivity database. The simulation image then is loaded onto a simulator and executed on the simulator (Step 86). During execution, the simulator checks for failed assertions (Step 88), and a determination is made whether an assertion has failed (90).
If an assertion has not failed, the simulation image continues to execute on the simulator (Step 86). Otherwise, as shown in FIG. 4, if an assertion has failed, the simulation is halted (Step 92). Once the simulation is halted, node data for the design is obtained (Step 94). The node data is used to determine the cause of the assertion failure. The node data may include specific values of signals on nodes at particular points of the simulation prior to the failure of the assertion. In order to reduce the number of nodes for which node data is obtained, the designer may use the connectivity database to obtain a fanin cone for the assertion(s) that failed. Thus, the designer may avoid obtaining unnecessary node data (i.e., obtaining node data for nodes that are not drivers for the nodes associated with the assertion that failed).
Once node data is obtained, the designer analyzes the node data to debug the failed assertion (Step 96). For example, the designer may determine that a particular gate associated with a node in the fanin cone is faulty, which caused an unexpected signal value, resulting in the failed assertion. In other cases, the designer may not be able to determine the cause of the failed assertion. For example, the node data obtained by the designer may be incorrect.
A determination is made as to whether the cause of the assertion failure is found (Step 98). If the cause of the assertion failure is found, the design is corrected and recompiled using the simulation toolkit, taking into consideration the cause of the assertion failure (Step 100). Then, a determination is made as to whether the assertions require modification (Step 102). If the assertions require modification, the designer modifies the assertions (Step 104).
Once the assertions are modified (or if modification is not required), a determination is made as to whether the simulation has completed (Step 106). If the simulation has not completed, Step 82 is performed; otherwise, the simulation ends.
Referring back to Step 98 of FIG. 4, if the cause of assertion failure is not found, then the designer modifies the assertions (Step 104), and if the simulation is determined to not be complete (Step 106), the assertion is inserted into the design (typically, by hard coding the modifications to the assertions within the simulation image) (Step 82). The design with the modified assertion is then compiled to generate the simulation image (Step 84). Next, the simulation is restarted and executed on the simulator (Step 86).
If, while the design is being executed on the simulator, the designer wishes to modify the assertions prior to discovering a failure, the designer may use the simulation toolkit to halt the simulation, obtain new assertions (Step 80), insert the new assertions into the design (Step 82), and recompile the design to generate another simulation image (Step 84), which is then loaded onto the simulator once more and executed (Step 86).